Networks such as the Internet and intranets continue to increase in popularity as vehicles to disseminate information, provide content, encourage collaboration, or otherwise facilitate communication. An integral part of content pages on these networks is the user interface for applications. Many developers create content using web authoring tools that allow developers to create pages of content using the tool, after which the tool generates the appropriate code to use on the network. Other developers write code manually, using markup tags as building blocks of the user interface for the application they are creating. Developers can utilize Hypertext Markup Language (HTML) markup tags, acquire third party tags from JavaServer Page (JSP)™ technology developers, or can develop their own markup tags. Markup tags are tags in an HTML document that instruct Web browser software on how and where to display the text or other content associated with the markup tag, create links between documents, etc. JSP is a standard developed by Sun™ Microsystems, Inc. (of Santa Clara, Calif.) to, for example, assist developers in building dynamic Web sites and accessing database information on a Web server.
As more content becomes available on the Internet (or on intranets), the need to provide accessible content increases. Without accessible code underlying Internet or intranet pages, users with disabilities cannot properly access some of the visual indicators in the standard user interfaces. Accessibility code provides, for example, a description of an image or a table so that users who cannot view the image or table because of a disability are instead provided its description. This allows those users to still access the content of the page (using text readers or other devices) even though they may not be able to see an image, table, or other content. Content developers who desire to make their content available to as wide an audience as possible accordingly desire to have accessible code. Moreover, many customers of web or other content, such as governmental agencies, often prefer or require that developers provide accessible code.
While accessible code provides a significant benefit, the cost of developing, testing, and troubleshooting accessible code can be very high. Most content developers developing accessible code first create the code and then send their code to Quality Engineering (QE) or other groups for verification of the accessibility of code and the user interface. If there are any errors (i.e., some of the code is non-accessible), the code is sent back to the developer to fix the identified bugs. After the code has been fixed, it must then be retested by the QE group. Such a process call be time-consuming and expensive, requiring the expenditure of resources by a QE group and potentially large delays in testing and fixing the code. These problems are exacerbated when using third party tag sets to generate the code, as most of the tag sets have not been configured to provide accessible code. Proper accessibility use of these tag sets is generally not enforced as many customers of these tag sets do not require accessible code.
One solution to this problem is to utilize the accessibility checking feature of WebKing® by Parasoft® Corporation of Monrovia, Calif. Using WebKing®, a developer may check completed code for accessibility problems at runt-time after they have properly configured the tool. The developer manually selects each page to be analyzed, allowing the program to perform a run-time check of the completed code and to produce an error report that identifies accessibility issues. This solution, however, still results in significant delays in producing accessible code as the developer must run the program at the end of a code cycle and then go back to fix any errors. The time required for QE groups is reduced, but developers must instead test the code for accessibility themselves and then redirect their development resources to fixing any problems. Another problem with the solution is that WebKing® cannot process content created with JavaScript®, making the use of JavaScript generated accessibility information more difficult. There is a need, therefore, for an effective mechanism to ensure the accessibility of developed content.